Method for sending messages over secure mobile communication links

ABSTRACT

Messages are sent over secure communication links in networks with a mobile terminal and another terminal. A secure communication link is established between an initial network address of the mobile terminal and the address of the other terminal. When the mobile terminal moves from the initial network address to a new network address, a request message is sent from the mobile terminal to the other terminal to change the secure connection to be used between the new address and the other terminal. The other terminal responds with a reply message with a description about the overcoming methods supported by the other terminal.

PRIOR APPLICATIONS

This is a US national phase patent application that claims priority fromPCT/FI03/00046, filed 21 Jan. 2003, that claims priority from FinnishPatent Application No. 20020113, filed 22 Jan. 2002.

TECHNICAL FIELD

The invention is concerned with methods for sending messages over mobilecommunication links, especially secure mobile communication links.

TECHNICAL BACKGROUND

An internetwork is a collection of individual networks connected withintermediate networking devices and functions as a single large network.Different networks can be interconnected by routers and other networkingdevices to create an internetwork.

A local area network (LAN) is a data network that covers a relativelysmall geographic area. It typically connects workstations, personalcomputers, printers and other devices. A wide area network (WAN) is adata communication network that covers a relatively broad geographicarea. Wide area networks (WANs) interconnect LANs across normaltelephone lines and, for instance, optical networks; therebyinterconnecting geographically disposed users.

There is a need to protect data and resources from disclosure, toguarantee the authenticity of data, and to protect systems from networkbased attacks.

The IP security protocols (IPSec) provides the capability to securecommunications between arbitrary hosts, e.g. across a LAN, acrossprivate and public wide area networks (WANs) and across the internet.

IPSec can encrypt and/or authenticate traffic at IP level. Traffic goingin to a WAN is typically compressed and encrypted and traffic comingfrom a WAN is decrypted and decompressed. IPSec is defined by certaindocuments, which contain rules for the IPSec architecture. The documentsthat define IPSec, are, for the time being, the Request For Comments(RFC) series of the Internet Engineering Task Force (IETF), inparticular, RFCs 2401-2412.

Security association (SA) is a key concept in the authentication and theconfidentiality mechanisms for IP. A security association is a one-wayrelationship between a sender and a receiver that offers securityservices to the traffic carried on it.

A security association is uniquely identified by parameters of which thefirst one, the Security Parameters Index (SPI), is a bit string assignedto this SA. The SPI enables the receiving system to select the SA underwhich a received packet will be processed. IP destination address is thesecond parameter, which is the address of the destination end point ofthe SA, which may be an end user system or a network system such as afirewall or a router. The third parameter is the secure protocol beingused, i.e., ESP or AH.

The term IPsec connection is used in what follows in place of an IPSecbundle of one or more security associations, or a pair of IPSecbundles—one bundle for each direction—of one or more securityassociations. This term thus covers both unidirectional andbidirectional traffic protection. There is no implication of symmetry ofthe directions, i.e., the algorithms and IPSec transforms used for eachdirection may be different.

Several networks, for instance many corporate and Internet ServiceProvider (ISP) networks, use so-called private IP addresses. These areaddresses internal to the network in question, and which cannot be usedin the Internet. The motivation is usually to conserve the use of publicIP addresses, the number of which is limited by the IP protocolspecification. If a message is sent from such a private network to acomputer outside the private network, e.g. to the public Internet, theprivate sender address needs to be translated into the public IP addressspace used in the Internet. This translation is referred to as theNetwork Address Translation (NAT) algorithm. A more comprehensiveversion of message address translation encompasses not only IP addressfields, but also transport protocol fields, such as TCP or UDP ports.This is done because the Transmission Control Protocol, TCP, and theUser Datagram Protocol, UDP, are widely deployed transport layerprotocols that are generally used with IP, and the TCP and UDP portnumber translations enable several sessions to be multiplexed to asingle public IP address. Such translations are often called NetworkAddress Port Translation (NAPT). The term NAT, in this document, refersto all such translation methods.

Some NAT algorithms support only a subset of existing IP-basedprotocols. That is, if a protocol that is not supported by a given NATdevice is used, the traffic using that protocol will be blocked by thedevice. The same applies if an ordinary intermediate host, e.g. arouter, is configured to block certain types of traffic. In such cases,the message can be encapsulated in another protocol that passes throughsuch intermediate computers. Tunnelling is one method for encapsulatingpackets of a given protocol into packets of another protocol, in orderto overcome such limitations posed by the intermediate computers. Thetunnelling is applied at the so-called entry point of the tunnel, whilethe reverse, i.e. uncovering the original packet, is done at theso-called exit point of the tunnel.

NAT traversal technologies are used to (1) determine whether a NATdevice (or several NAT devices) exist in the route between twocommunicating hosts, and to (2) perform necessary encapsulation toovercome the NAT translations. There might also be other translations,such as protocol translations, performed by a NAT device or anotherintermediate device. For instance, IPv4 may be translated to IPv6, andvice versa.

When secure messages are desired to be sent from a network requiring NATtranslations, the IPSec protocols can be used. There exist severalsolutions for IPSec NAT traversal. The Internet Engineering Task Force(IETF) is currently in the process of standardising a solution for IPSecNAT traversal.

Even though IPsec provides a strong security solution that alreadysupports traversal through NAT devices, IPsec is static in nature. Ifeither of the hosts sharing an IPSec SA are mobile, i.e. a host movesfrom one IP network to another, a new security association must be setup each time such movement takes place. This usually involves an IKEprotocol execution.

Such an IKE protocol execution involves several round trips in order toset up a new SA for the new network used. In a known IPSec NAT traversalmethod, developed in the IETF, the key exchange phase requires the useof IKE main mode, which consists of six messages, followed by IKE quickmode, which consists of three messages, for a total of nine messages. Ifthe IKE aggressive mode, which consists of three messages, is usedinstead of main mode, a total of six messages are required.

There are several disadvantages of this solution. Firstly, the roundtrip times may be considerable if there is a considerable routinglatency between the new network and the other IPSec endpoint. Thelatency between two communicating nodes is usually measured in terms ofround trip delay (also called round trip latency). A round trip latencyis a measure of the time it takes for a packet to be sent from onecommunicating node to another, and for the other node to send a replypacket back to the sender.

For instance, if the network has a round trip latency of 500 ms, whichis not unusual, and IKE main mode is used, the total network latency foran IPSec connection setup is 500×(9/2) ms=2250 ms. This may beunacceptable for some mobile applications. Secondly, the IKE keyexchange requires the use of several computationally expensivealgorithms, such as the Diffie-Hellman algorithm, and possibly the RSAsignature and signature verification algorithms. Such algorithms mayrequire considerable computation for mobile devices, which may belimited in their processing power.

THE OBJECT OF THE INVENTION

The object of the invention is a method for sending messages over mobilecommunication links, which supports protocol traversal and secure mobilelinks.

SUMMARY OF THE INVENTION

The method of the invention for sending messages over securecommunication links is used in networks comprising at least one mobileterminal and at least one other terminal. There might be intermediatecomputers between the mobile terminal and the other terminal thatperform network address translation and/or other translations. A securecommunication link is established between a given initial networkaddress of the mobile terminal and the address of the other terminal. Inthe method of the invention, the secure communication link defines atleast the addresses of the two terminals. Furthermore, the securecommunication link supports some method, e.g. an encapsulation method toovercome network address translations and/or other translations. Whenthe mobile terminal moves from an initial network address to a newnetwork address, a request message is sent from the mobile terminal tothe other terminal to change the secure connection to be between the newaddress of the mobile terminal and the other terminal. The request issent using said method to overcome network translations, e.g. anencapsulation method. The request also contains information to enablethe other terminal to detect the existence and nature of translationsperformed by possible intermediate computer(s). The request alsoindicates the overcoming methods supported by the mobile terminal. Theother terminal responds to the mobile terminal with a reply message witha description about the overcoming methods, such as encapsulations,supported by the other terminal and/or about possible translations madeby intermediate computer(s) situated between the other terminal and thenew address of the mobile terminal. All messages are thereafter sentfrom the mobile terminal to the other terminal by using the informationsent with said reply.

The term mobile terminal here does not necessarily indicate physicalmobility. Rather, the mobile terminal is considered mobile if it changesits method of network access. This does not necessarily require physicalmobility.

Some advantageous embodiments are described in the following.

The term registration request (RREQ) is used for the message used by themobile terminal to request a change in the address of the secureconnection. The term registration reply (RREP) is used for the messagethat the other terminal uses to reply to a registration request. Thesetwo messages are preferably similar to the messages of the same nameused in the Mobile IP standard, but their precise contents are notessential to the invention.

Essential in the invention is the fact that when a mobile terminal movesto a new address and sends a registration request message (RREQ) to theother terminal, it does not know which protocols or rules are usable inthe new communication link. It does not even know if there are anyintermediate computers in the new communication link that perform e.g.Network Address Translation (NAT) and/or other translations.

The request message is therefore in a preferable embodiment sent usingsuch encapsulation protocols, that is considered the most general and issupported by as many converting intermediate computers, such as NATdevices, as possible. This means that the registration request messageis sent by the mobile terminal e.g. in a way that uses the “bestpossible” method of traversal available (e.g. UDP or TCP tunnelling asencapsulation method). This increases the chance that the RREQ alwaysreaches the other terminal, regardless of the possibly existing NATdevices in the route between the mobile terminal and the other terminal.

The RREQ includes a description of the message that, generally,indicates the address of the mobile terminal and the encapsulationprotocols including parameters used therein. Or the basis of thedescription, the other terminal can determine whether for example anyintermediate devices have modified the (packet) message on route or not.

The exact information included in the description of the message dependson the nature of the intermediate computer(s) and the encapsulationmode, but usually, the information includes the source and destinationIP addresses used in the outermost header of the message. Furthermore,transport layer sub-addressing information might be included, such asTCP and UDP ports. Encapsulation methods other than the above examplerequire entirely different encapsulation information. For instance, anencapsulation method based on encapsulating messages inside HyperTextTransfer Protocol (HTTP) messages requires entirely differentencapsulation information. However, the general idea remains the same.

Thus, the registration request includes information of how the messagewas encapsulated by the mobile terminal prior to sending. For instance,if UDP encapsulation is used, the request includes typically thefollowing fields:

-   -   IP source address    -   IP destination address    -   UDP source port    -   UDP destination port

NAT devices would typically manipulate the IP source address andpossibly the UDP source port, but also the destination address and portfields can be manipulated However, the devices would not manipulate thecopies of these fields, sent inside the request message, which thusserve as a method for detecting such changes.

After receiving of the request message by said other terminal, the otherterminal may determine by examining the request which translationsand/or encapsulations have been performed by devices situated betweenthe mobile terminal and the other terminal.

The terminal then sends a registration reply message containinginformation about the communication link to be used between the newaddress of the mobile terminal and said other terminal and which issupported by the other terminal. The message may include informationabout the NAT translations, protocol translations, and othertranslations detected by the other terminal, and parameters related tosuch translations. The message may also include an indication of whichencapsulation method(s) should be used for communication through the newcommunication link, and their parameter(s). The reply message is sentusing an encapsulation method, preferably using the same encapsulationmessage as was used for the request message. The encapsulation method(s)used, and their parameters can, in one embodiment, be included in thereply message to enable the mobile terminal to independently detect thetranslations in the same way as the description of the message earlierwas included in the request message.

The other terminal detects the translations performed in theregistration request message e.g. by comparing the actual header fieldsin the message to those fields which, prior to the sending, was includedin the message and which are not translated. Examples of fields to becompared are the outer IP header and/or the UDP header, if UDPencapsulation was used. A discrepancy in the fields indicatestranslation by one or more intermediate computer(s). The nature of thetranslation, e.g. whether an address or address-and-port translation wasperformed, can be similarly detected by comparing fields.

When sending its registration reply, the other terminal indicateswhether NAT traversal is required, based on the detected discrepancy offields discussed above. That is, the other terminal determines whatencapsulation method should be used.

In said another alternative, in which an encapsulation method(s) isused, wherein the parameters, was included in the reply message toenable the mobile terminal to independently detect the translations, themobile terminal may itself determine the need for traversal, and choosewhat encapsulation method is to be used.

If the mobile terminal notices that both its own and the otherterminal's views of the exchanged packets are the same, it is anindication on that NAT devices do not exist on the route, and NATtraversal is not necessary. Alternatively, according to the firstmentioned embodiment, the other terminal may detect that no translationswere performed, and indicate to the mobile terminal that encapsulationis unnecessary.

If there appear to be no NAT devices on the route, the mobile terminalmay drop the NAT traversal directly, although in rare situations theconnection may still not work without traversal. For instance, packetfiltering routers, also known as firewalls, may prevent communicationusing some protocols while allowing communication with other protocols,while still not doing protocol translation. For this reason, they cannotgenerally by detected on the basis of packet modifications. Instead,some protocols simply either go through them, or do not go through them.This may cause the registration message(s) to go through thefirewall(s), while actual traffic after registration may not go throughthem.

The mobile terminal should preferably detect this occurrence, and switchback to an encapsulation mode, preferably to the one used forregistration and which is already known to go through the intermediatecomputer(s). Alternatively, the mobile terminal may send a probe packetthat is not encapsulated using the method used in the registration, andif the other terminal replies to the probe, it is a strong—but notcertain—indication on that un-encapsulated traffic is allowed by theintermediate computer(s). When such a probing protocol is used, datatraffic can be sent using this encapsulation method until the results ofthe probing are known. In case the probing is allowed by the firewall(s)but some particular protocol used in the data traffic is not, the mobileterminal should preferably switch back to the first encapsulation mode.

The secure connection is preferably formed using the IPSec protocol,whereas the messages in the communication are sent using IPSec andpossibly a NAT traversal encapsulation, preferably UDP or TCPencapsulation of IPSec packets. In the invention, the secure connectioncan be updated efficiently to the new network address of the mobileterminal. The messages can be sent without NAT traversal or otherchanges in the communication link if, on the basis of the comparisonmade by the mobile terminal, the descriptions of the messages correspondto each other or if it is informed by the other terminal thatencapsulation to overcome NAT and/or other translations is unnecessary.Even in that case it might be so that encapsulation is performed anywayto ensure that undetectable translations and/or packet filtering do notprevent traffic from being sent.

The secure communication link that is established between the mobileterminal and the other terminal is, as was already stated by means ofthe IPSec protocol, is called IPSec connection in this text. Thus, therequest sent from the mobile terminal contains information about the newconnection to be used.

For forming the IPSec connection, a key exchange mechanism that passesthrough NAT is used. If the intermediate computer(s) allow the UDPprotocol, possibly doing UDP port translation, the IKE key exchangeprotocol can be used with very minor modifications. Any key exchangeprotocol can be easily made to go through NAT devices by using a properencapsulation protocol—or set of protocols—for key exchange messageencapsulation. It is also feasible to use several encapsulationmechanisms simultaneously to increase the chance that at least one ofthem passes through the intermediate computer(s).

In the invention, an application connection can e.g. be establishedbetween the mobile terminal and a host connected to the other terminal(in which case the host is referred to as “the other terminal” in thetext) or directly between the mobile terminal and the other terminal.The IPsec connection is between the mobile terminal and the otherterminal. In the foregoing case, tunnel mode is used in the IPSeccommunication, whereas in the latter case, transport mode can be used.However, IPSec tunnel and transport mode are interchangeable. IPSectransport mode can be replaced by IPSec tunnel mode, and IPSec tunnelmode can be replaced by IPSec transport mode and possibly a tunnellingprotocol, such as the Layer 2 Tunnelling Protocol (L2TP).

In a further embodiment, several request messages can be sent, eachprocessed using a different traversal mechanism (e.g. UDP NAT traversal,TCP NAT traversal, HTTP tunnelling, etc), where after the other terminalindicates in the reply which methods is to be used in the furtherconnection.

The data packets that follow are encapsulated using a traversalmechanism that is either chosen beforehand, or negotiated dynamically inthe registration request/registration reply exchange. In that case, NATtraversal is used unconditionally for the registrationrequest/registration reply exchange and the traversal is disabled if itseems that it is unnecessary.

The advantages of the method of the invention are that:

The NAT traversal detection is independent of the keying mechanism (IKE)and that the NAT traversal state, i.e. whether traversal is disabled orenabled, and other associated parameters, is not a static part of theIPSec connection, but can instead be modified using the RREQ/RREPmessage exchange to suit a new connection point.

The handover, i.e. a connection from one network address to another,requires half a roundtrip for the server-to-client data to startflowing, and one roundtrip for the client-to-server data to startflowing. Compared to standard IPsec, this is a major improvement,enabled by the changeable nature of the modified IPsec SA described inthe application, and the registration procedure that detects and reactsto NAT devices in a single round trip.

FIGURES

FIG. 1 is an example of a network wherein the method of the inventioncan be applied.

FIG. 2 is a signalling diagram illustrating an embodiment of the methodof the invention.

DETAILED DESCRIPTION

FIG. 1 describes an example of a network wherein the method of theinvention can be applied. Thus, to the network belongs a mobile terminal1 that has an IPSec SA, here called IPSec SA 1, established between themobile terminal 1 and another terminal 2, the IPSec SA 1 supporting thetranslations made by NAT 1. When the mobile terminal 1 moves to anotheraddress indicated by the arrow a new IPSec SA 2 has to be establishedbetween the terminal 1′ the same mobile terminal but marked with 1′ asit has moved) and the other terminal 2. The NAT 2 device might supportother protocol translations than NAT 1.

In the invention, IPSec SA 2 is established by modifying the existingIPSec SA 1 using a signalling mechanism. In the prior art method, IPSecSA 2 is established either manually or using some automated key exchangeprotocol, such as IKE, with the disadvantages stated previously.

The example of the method of the invention described in FIG. 2 takesplace in a network of FIG. 1. The mobile terminal is in FIG. 2 called Xand the other terminal is called Y.

In FIG. 2, there is first established an IPSec SA connection between themobile terminal X and the other terminal Y. The signalling exchange forinstance the IKE protocol execution is indicated by reference 1 in FIG.2. In all communication between X and Y, NAT translations are performedby the NAT1 device and the IPSec connection formed supports NATtraversal to overcome these translations.

When the mobile terminal X moves to another address indicated by step 2in FIG. 2, it performs a registration request/registration replyexchange with Y to indicate to Y that a new IPSec SA (IPSec SA 2) is tobe used for future packets destined to Y and to determine whethertraversal is needed or not in the future communication.

It is assumed that X does not know anything about NAT2, not even if sucha device exist in the route or not. The request message is indicated inFIG. 2 by the fields IP/UDP/ESP/IP/RREQ indicating that IPSec ESPprotection is applied and UDP encapsulation to assert NAT traversalmechanism to overcome possible NAT translations made by NAT 2. Thismessage is sent in step 3 through NAT 2 which makes translations in step4.

In step 5, the message is forwarded to host Y after translation in NAT2. In steps 3-8, X establishes IPSec SA 2 by means of the signallingmessages. A reply message is sent back from Y in step 6 with informationabout whether NAT traversal is needed for this connection point. In NAT2 address and other translation takes place as usual in step 7 and themessage after that goes further to the mobile terminal X in step 8.

FIG. 2 uses IPSec ESP tunnel mode as an example, but any other IPSecconnections may be used, for instance IPSec in transport mode.

1. A method for sending messages over secure communication links innetworks, comprising: providing at least a first terminal incommunication with a second terminal, establishing a first securecommunication link between an initial network address of the firstterminal and a network address of the second terminal, the firstterminal performing encapsulation of messages sent in the first securecommunication link using a first encapsulation method, the firstterminal moving from the initial network address to a new networkaddress, the first terminal sending an encapsulated request message,using the first encapsulation method, to the second terminal to changecommunication between the first terminal and the second terminal fromthe first secure communication link to a second secure communicationlink extending between the new network address of the first terminal andthe network address of the second terminal, the encapsulated requestmessage containing a description of the first encapsulation methodperformed by the first terminal, the second terminal receiving theencapsulated request message, the second terminal using the descriptionof the first encapsulation method to detect translations of theencapsulated request message performed by intermediate computersdisposed en route between the first terminal and the second terminal,the second terminal responding to the first terminal with a replymessage, the reply message having a description about detectedtranslations made by intermediate computers disposed between the newnetwork address of the first terminal and the network address of thesecond terminal and/or encapsulation methods supported by the secondterminal, the first terminal receiving the reply message and thedescription about translation made by intermediate computers andencapsulation methods supported by the second terminal, the firstterminal selecting an encapsulation method to encapsulate a messagebased on the description of the reply message, and the first terminalsending the encapsulated message to the second terminal.
 2. The methodof claim 1 wherein the method further comprises the second terminaldetecting address translations performed by the intermediate computersand including a description to translated source and/or destinationaddresses in the reply message.
 3. The method of claim 1 wherein thedescription of the reply message has information about encapsulationprotocols, as well as source and destination transmission controlprotocol (TCP) or user datagram protocol (UDP) ports.
 4. The method ofclaim 3 wherein the method further comprises performing network addresstranslation (NAT) traversal by UDP encapsulation or TCP encapsulation.5. The method of claim 1 wherein the method further comprises the secondterminal examining the encapsulated request message to determine whichtranslations and/or encapsulations are required in traffic between thefirst terminal and the second terminal.
 6. The method of claim 5 whereinthe reply message contains information about the second securecommunication link to be used between the new network address of thefirst terminal and the second terminal.
 7. The method of claim 6 whereinthe information about the second secure communication link includesinformation about whether network address translation (NAT) traversal isused.
 8. The method of claim 1, wherein the method further comprises thefirst terminal comparing the description of the request message with thedescription of the reply message and sending subsequent messages fromthe new network address based on the comparison of the descriptionsregarding which encapsulations, protocols and rules to use.
 9. Themethod of claim 1 wherein the first secure communication link is formedby using an Internet security protocol IPSec.
 10. The method of claim 9wherein the reply message is sent by using IPSec and a network addresstranslation (NAT) traversal that is updated to the new network addressof the first terminal.
 11. The method of claim 1 wherein the replymessage is sent without a network address translation (NAT) traversal inthe first secure communication link when the description of the replymessage corresponds to the description of the request message.
 12. Themethod of claim 1 wherein the method further comprises providing a thesecure connection with an Internet security protocol (IPSec) securityassociation (SA).
 13. The method of claim 12 wherein the method furthercomprises using a key exchange mechanism that passes through a networkaddress translation (NAT) when forming the IPSec SA.
 14. The method ofclaim 12 wherein a key exchange mechanism is an Internet key exchange(IKE) when a network address translation (NAT) device supports a userdatagram protocol (UDP).
 15. The method of claim 14 wherein the keyexchange mechanism is used when forming the IPSec SA and wherein severaltraversal mechanisms are used simultaneously to increase a chance thatat least one of the traversal mechanisms passes through the NAT device.16. The method of claim 12 wherein a key exchange mechanism is performedwhen forming the IPSec SA in which a negotiation process is used toagree on protocols to be used in the further communication.
 17. Themethod of claim 12 wherein an encapsulation protocol is used in a keyexchange mechanism when forming the IPSec SA.
 18. The method of claim 1wherein the network address of the second terminal is an end destinationaddress of messages sent from the first terminal and using casetransport or tunnel mode in the first and second secure communicationlinks.
 19. The method of claim 1 wherein a destination address of themessage is a network address of a host which is not the second terminaland using tunnel mode or transport mode together with a tunnelingprotocol the first and second secure communication links.
 20. The methodof claim 1 wherein several request messages are sent, each requestmessage being processed using a different traversal mechanism and thesecond terminal indicating in the reply message which encapsulationmethod is to be used.